MS-DOS_Tips Hi Folks! I'd like to share some of my time-saving tips in MS-DOS. Since being introduced to the operating system some time ago, I've spent many hours attempting to develop ways to save time while programming. Programming involves the use of every resource available from your PC. When I refer to "PC" I am addressing any MS/PC-DOS compatible computer. The Public Domain has to be the most informative source of ideas I have ever come across. I will have to admit that 50% of my programming conceptions originate in the PD. I contribute to the PD as much as the next guy so I feel using the resource is permissible. My point is that for information and examples to follow, the PD is the place to look. The electronic bulletin board network is the best source for PD. With the low cost of modems and the availability of incredibly feature-packed modem programs in the PD (read: free), I see no reason not to plug in to the resource gold mine. Unless you only occasionally use your PC for applications programs only, GET A MODEM! Throughout this article I will refer to MS-DOS synonymously with PC-DOS. Also, all references are to my Kaypro 286i system. My drives are configured as follows. A and B are 1.2 megabyte floppies. C and D are 21.5 megabyte hard disks. Some of the procedures outlined below may not be suitable for 360K floppy based systems. I do also use all the procedures outlined below on my Kaypro 16. A and B are 360K floppies. C is a 10 megabyte hard disk. I think the Kaypro 16 is the most popular of the pseudo-16 bit Kaypro systems so the procedures will apply to it. MS-DOS has this great built-in facility called batch processing. In the old days (two years ago?) batch processing referred to the use of a main-frame computer in slices of time. All processes needing CPU time were bundled together on punch cards and all fed in at one time. They were sequentially processed generating corresponding output or files and then the next member of the batch was processed. There was no benefit of interactive use of the computer. You had one chance to get it right or else you resubmitted the whole batch again the next day. With the introduction of the personal computer, interactive utilization of the machine is possible. But with all this technology, we find ourselves in redundancy sometimes. There is a way out. Many sequences of commands are used daily by the operator in MS- DOS that can be batched together. There are two simple ways to create a batch file. One is to use a text editor. I use EDLIN just because of it's simple command set and small size and fast speed. Believe me, it's not much of an editor for anything more than that. The other way is by device redirection. Here's an example: C: CD \FRED MARTHA If you entered this list of commands into a file called HARRY.BAT, every time you typed HARRY at the DOS command prompt, the COMMAND.COM resident processing system would read the commands from this file one line at a time. First we would log into drive C. Then change to the directory on that drive named FRED. Now the system would run a program named MARTHA. If you include a program name after MARTHA, then as soon as MARTHA is through running, the COMMAND.COM processor remembers you have another command to execute and will do just that. You can string these things out as far as you want. In fact, you can use the COMMAND /C command to load another COMMAND.COM processor and use the DOS commands in it just like before. Now as soon as you type EXIT at the DOS prompt, the first COMMAND.COM processor will take over and execute the remaining commands. I'll give you an example: C: CD \FRED MARTHA COMMAND /C WP Suppose you have a file called DO-IT.BAT on your disk. It contains the list of commands shown above. Typing DO-IT at the DOS prompt will log into drive C, change directory to FRED, run a program called MARTHA and as soon as MARTHA was finished you would see a DOS prompt. You are not really where you started. You are now within a second DOS command processor. You can execute any DOS command you want. Now as soon as you type the command EXIT, you are returned to the first command processor and it will pick up where it left off, executing the program called WP. This was a case of "nesting" the command processor. In CP/M the equivalent of the command processor is called the CCP. ZCPR was a great attempt to help the user in CP/M to accomplish some of the tasks available in DOS. The second method of generating a batch file is called device redirection. It's really a quite fast economical way to generate any small file. DOS treats everything it is connected to as a device. The CRT, keyboard, disk drives, serial port etc. are all devices to DOS. You have the ability to copy files, or actually any data string, to and from the different devices. You probably already know that any time you append a ">PRN" to a command, all output from the command is redirected to the printer. You can redirect to a file also. ">FRED" appended to a command would send all output from the command to a file called FRED. If you want to add (append) stuff to the end of an already existing file just use two ">"'s. As in TYPE FILENAME.EXT >>FRED. This would send all printable characters sent to the screen to the end of an existing file named FRED. These examples of I/O redirection are fairly popular and documented. One type of redirection is all too often ignored. COPY CON is a form of redirection that is handy in creating small batch files. If you type "COPY CON FRED.BAT" all keys typed on the keyboard and generated on the screen will be sent to a file named FRED.BAT. You have now created a batch file. The return key will generate a carriage return character in the file. To end the redirection and close the file use the end-of-file character CTRL-Z. You can hold down the CTRL key or use the F6 function key. Actually all the command accomplished was the copying of one devices output (CON) to another device. (in this case the other device was a file named FRED) (Is that anything like a boy named Sue?) DOS users will tell you that there is one thing batch files will not accomplish; the ability to run another batch file, then after it is finished, return to the originating batch file to continue processing. AHA! Not true. You can execute another batch file as a "subroutine". A subroutine, as defined in the Mike Stickney Fanatic Programmer's Manual, is a procedure, function or complete program called from another procedure, function or program; after which a return is made to the calling procedure, function or program. In other words, do something and come back when you're finished. If you use the COMMAND /C with a batch filename, DOS will load another command processor, execute the batch file and as long as the batch file has an EXIT command in it, return to the point in the originating batch file after the last command issued. The syntax (no, not a tax on sex, but the required spelling, etc.) of the command is "COMMAND command /C". Where "command" is any DOS command or batch filename. Just remember to put the EXIT command in the called batch file. Here's a tricky one. Have you ever wanted to have a batch file go to another directory, issue a command, and return to the directory area that it was called from? Sure, you could put a "CD \directory" command at the end of the batch file. What happens when you call this batch file from another directory? If your path is set properly, IE: multiple paths of which one points to the directory area where all your batch files are stored, you can call your batch files from ANYWHERE in ANY disk drive. I figured out a way to accomplish a return to the calling directory area. (I'll admit I saw an article in the latest PC magazine that accomplishes this in a manner similar to mine, but I figured out mine first!) First I'll list the batch commands below that accomplish this. The commands are in a file named SAVDIR.BAT. DEL C:\BAT\RETDIR.BAT >NUL COPY C:\BAT\CD.TXT C:\BAT\RETDIR.BAT >NUL CD >>C:\BAT\RETDIR.BAT EXIT This list assumes a file already exists in C:\BAT named CD.TXT. CD.TXT contains the characters "CD ". I have my directory search path set up as follows: PATH=C:\DOS;C:\BAT;C:\;C:\NORTON;C:\UTILITY;C:\WP;D:\MOUSE As you can see, I have a path set to my C drive \BAT directory. My \BAT directory contains all my batch files. This way whenever I need a batch file I need only type the batch command name at the prompt. DOS will search along the paths for the directory containing the batch file. This might get a little complex so please read this a few times until you understand it. The only other thing you need is the awareness that when you want the batch file to return to the calling directory area, you issue the command RETDIR. Now I'll outline what all this mess does. This refers to the four line batch file listed above named SAVDIR.BAT. Line 1) Delete any file in the \BAT directory on the C drive named RETDIR.BAT. This gets rid of any RETDIR batch file left over from the last use. Line 2) Copy the contents of CD.TXT ("CD ") to a file named RETDIR.BAT. The >NUL on the end sends all output to the NUL device. The NUL device is just like it sounds, meaning send output to never-never land. In other words, don't clutter up the screen with crap when you don't have to. Otherwise you'll see "1 file(s) copied" and this might be confusing. Line 3) Issue a CD command and append the output to the file we created above. Issuing CD by itself will cause DOS to print out the curent disk and directory. Since we redirected the output to the RETDIR.BAT file, now we have a command in a batch file that will take us back to where we originated. All references to the files have their full paths preceding them so the files will always be found in the same place. The issuance of the command "RETDIR" will cause the RETDIR.BAT file to be executed which contains the command we need. Line 4) EXIT back to the originating command processor. The only thing you need be aware of at this point is that the SAVDIR command must be executed as a child process of COMMAND.COM. In other words we need to run SAVDIR like a subroutine so that when the SAVDIR batch file is done, we are returned to the originating batch file that has the commands we needed to process in the first place. This is done as described earlier. "COMMAND SAVDIR /C". I have found one limitation with this process. It will not change the logged disk drive. If you call this procedure from drive D and the commands you are executing take you to drive C, you will remain in drive C. Now the SAVDIR/RETDIR stuff hasn't completely been wasted. Whenever you issue the CD command specifying a different disk drive, the "default" directory on the drive will be changed to what you specify. Remember, when you type CD all by itself DOS outputs the drive and directory presently occupied. Since we use the CD command to generate our RETDIR batch file, the command generated will contain the disk drive prefix. If all our batch commands keep us in the same drive, we're okay. Changing the default directory of the drive you are presently logged into is the same as logging into that directory. If you do use this procedure to migrate from drive to drive, all you have to do after the batch file is done is change drives. The originating directory area will be the one you are automatically dropped into. As you can see, you can make batch file processing as simple or as complex as you want. With all the commands available to you at the DOS prompt, you really have a whole new programming language suitable for minor housekeeping chores. Mike Stickney, SYSOP - SKUG